AWS ALB(新しいELB)のホストベースルーティングとSSL/TLS証明書の関係を理解する

大瀧隆太

2017.04.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。
本日、AWSの新しいロードバランサALB(Application Load Balancer)でホストベースルーティングがサポートされました。早速以下の記事で検証しています。

【新機能】ALBのHost-based routingを試してみた｜ Developers.IO

今回の機能追加によって、ロードバランサ自身にホストベースのバーチャルホスト機能が追加されたわけですね。使い勝手大幅アップ！という感じなのですが、ホストベースバーチャルホストとHTTPSを提供するためのSSL/TLS証明書は切っても切れない重要な関係かなと思い、その組み合わせについて調べてみました。

結論から言うと、現時点でALBの同一のポートでホスト名ごとに証明書を分けることはできません。ワイルドカードやマルチドメインなど複数のホスト名を1つの証明書で扱う対応を検討しましょう。

2017年10月にALBが複数証明書に対応したため、現在は証明書の使い分けが可能です。
ALBで複数のSSL/TLS証明書を設定できるSNIに対応しました｜ Developers.IO

ALBの構成要素と紐付け

まずは、ルーティングと証明書がロードバランサとどう紐付けられるのか、ALBの設定から構成要素とその紐付けを整理します。

ALBの構成要素

ざっと挙げると以下になります。

ロードバランサ(Load Balancer) : ALB本体。
リスナ(Listener) : ALBで待ち受け(Listen)るポート。
証明書(Certificate) : HTTPSをListenするためのSSL/TLS証明書。ACMとIAMに対応。
ルール(Rule) : 転送先のターゲットグループを決定するための条件。現在はHostヘッダとリクエストパス(あるいは両方)を設定。
ターゲットグループ(Target Group) : トラフィックを転送するEC2を指定するグループ。

他にも、ターゲットに紐付くヘルスチェックやEC2インスタンス/AutoScalingグループもありますが、今回は省略します。で、紐付けを図にすると以下になります。

Load_Balancer
├── Listener_1
│   ├── Certificate_1
│   ├── Rule_1
│   │   └── Target_Group_1
│   └── Rule_2
│       └── Target_Group_2
└── Listener_2
    ├── Certificate_2
    ├── Rule_3
    │   └── Target_Group_3
    └── Rule_4
        └── Target_Group_4

ポイントは証明書とルールが同じ階層にあるところで、複数のホストベースのルールとそれに対応する証明書を紐付けるのは、仕組み上できないことがわかるでしょう ^*1。

リスナと証明書の関係

また、リスナに設定する証明書は、リスナを作成するCreateListener APIなどを一見するとArray(配列)なので複数設定できるように見受けられます。

CreateListener - Elastic Load Balancing
Certificates.member.N
- The SSL server certificate. You must provide exactly one certificate if the protocol is HTTPS.
- Type: array of Certificate objects
- Required: No

しかし、Descriptionをよく見ると、「You must provide exactly one certificate if the protocol is HTTPS.」とあるので、リスナ(≒ポート)につき証明書は1つしか設定できないことがわかります。

実際にAWS CLIなどで複数の証明書をリスナに設定すると、リストに指定した最後の証明書のみが有効になることを確認しました。